-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Test-fix testAcceptsMismatchedServerlessBuildHash #121869 #122332
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Pinging @elastic/es-distributed-indexing (Team:Distributed Indexing) |
|
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
|
Hey @thecoop, I'm wondering why system property is different, am I missing something. It was like this for 1.5 years. |
|
This might be something @DaveCTurner has been modifying... |
|
I dont see "es.serverless" property in the code base, probably a mistake. This should be a valid fix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense to me, but I had a concern about the reliability of the test before the change (see comment).
| assumeTrue("Current build needs to be a snapshot", Build.current().isSnapshot()); | ||
| assumeTrue("Security manager needs to be disabled", System.getSecurityManager() == null); | ||
| System.setProperty("es.serverless", Boolean.TRUE.toString()); // security manager blocks this | ||
| System.setProperty(TransportService.SERVERLESS_TRANSPORT_SYSTEM_PROPERTY, Boolean.TRUE.toString()); // security manager blocks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the test reliably fail before this change? You mentioned reproducing it, but I wasn't sure of the frequency.
I'm wondering why this didn't fail in the first place when it was added. Maybe we could bundle the try-block logic into a method, and exercise it once with System.setProperty(TransportService.SERVERLESS_TRANSPORT_SYSTEM_PROPERTY, Boolean.TRUE.toString()); set to true (succeeds) and then a second time set to false (should throw)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the test reliably fail before this change?
yes, test fails every time with
./gradlew ":server:test" --tests "org.elasticsearch.transport.TransportServiceHandshakeTests.testAcceptsMismatchedServerlessBuildHash" -Dtests.seed=8278A46E39005C96 -Dtests.jvm.argline="-Des.entitlements.enabled=" -Dtests.locale=en-001 -Dtests.timezone=US/Pacific -Druntime.java=24
I believe test suppose to test this flag by going through debugger.
elasticsearch/server/src/main/java/org/elasticsearch/transport/TransportService.java
Lines 694 to 698 in c27bc08
| private void maybeThrowOnIncompatibleBuild(@Nullable DiscoveryNode node, @Nullable Exception e) { | |
| if (SERVERLESS_TRANSPORT_FEATURE_FLAG == false && isIncompatibleBuild(version, buildHash)) { | |
| throwOnIncompatibleBuild(node, e); | |
| } | |
| } |
But it set with "es.serverless_transport".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could bundle the try-block
Do you mean put System.setProperty inside try-catch? I dont think System.setProperty throws here. Also if it throws entire test case will not run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, then it reliably fixes the test 👍 Thanks.
Optionally I'd suggest making the test more robust by also proving the test setup would normally throw, and then verifying that it does not throw with the serverless Property set -- e.g. put the try-block code in a method and call it twice, with and without the Property setting. But that's a test improvement, not a test fix, so I don't feel strongly about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was curious why it started to fail now since all related changes have been around more than 1 year. It turns out the reason is that the test was never executed because of the following line
elasticsearch/server/src/test/java/org/elasticsearch/transport/TransportServiceHandshakeTests.java
Line 379 in 3c18ea6
| assumeTrue("Security manager needs to be disabled", System.getSecurityManager() == null); |
SecurityManager is removed in JDK 24. Hence it started to fail now with JDK24 while it is skipped when running with all prior JDK versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the test was "muted" for all this time? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think it definitely has Not ran since #95754
DiannaHohensee
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| assumeTrue("Current build needs to be a snapshot", Build.current().isSnapshot()); | ||
| assumeTrue("Security manager needs to be disabled", System.getSecurityManager() == null); | ||
| System.setProperty("es.serverless", Boolean.TRUE.toString()); // security manager blocks this | ||
| System.setProperty(TransportService.SERVERLESS_TRANSPORT_SYSTEM_PROPERTY, Boolean.TRUE.toString()); // security manager blocks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, then it reliably fixes the test 👍 Thanks.
Optionally I'd suggest making the test more robust by also proving the test setup would normally throw, and then verifying that it does not throw with the serverless Property set -- e.g. put the try-block code in a method and call it twice, with and without the Property setting. But that's a test improvement, not a test fix, so I don't feel strongly about it.
…stic#122332) (cherry picked from commit 49ecbca)
…stic#122332) (cherry picked from commit 49ecbca)
…stic#122332) (cherry picked from commit 49ecbca)
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
…123477) (cherry picked from commit 49ecbca) Co-authored-by: Mikhail Berezovskiy <[email protected]>
…123478) (cherry picked from commit 49ecbca) Co-authored-by: Mikhail Berezovskiy <[email protected]>
…123476) (cherry picked from commit 49ecbca) Co-authored-by: Mikhail Berezovskiy <[email protected]>
Fixes #121869
testAcceptsMismatchedServerlessBuildHashuses wrong system property name"es.serverless"but should be"es.serverless_transport".